|
|
| Author |
Thread Statistics | Show CCP posts - 24 post(s) |
Abdiel Kavash
Paladin Order
Fidelas Constans
2123
   |
Posted - 2013.12.03 17:33:00 -
[1] - Quote
I am slightly confused. You started the devblog by asserting that the old system was bad, because it put clusters of connected systems on one node (and intra-node jumps are more expensive than inter-node jumps). Yet you end up with a system that puts even bigger clusters of connected systems on the same node? From the pictures it looks like instead of constellations, now huge chunks of regions share the same node. Wouldn't that lead to even more intra-node jumps?
I think that a way more optimal solution would be a kind of checkerboard-style distribution, where systems on one node are geographically close together (to save the poor trio of ratters in Solitude), but not directly connected to other systems on the same node. Several nodes could therefore share the load from people jumping in and out of a big fleet battle, and the majority of jumps would be inter-node jumps.
As others have already said, the new allocation could lead to even higher load being put on the nodes in battles, as it seems now that any sort of reinforcements or auxiliary fights will directly contribute to the load of the fleet fight node itself. And this will also happen with a pre-reinforced node - even if you take the contested system out of the picture, all the surrounding area still shares the same node. Whereas in the old distribution, it is rare to even find a system whose direct neighbors are all on the same node. |
Abdiel Kavash
Paladin Order
Fidelas Constans
2124
|
Posted - 2013.12.03 17:35:00 -
[2] - Quote
I am slightly confused. You started the devblog by asserting that the old system was bad, because it put clusters of connected systems on one node (and intra-node jumps are more expensive than inter-node jumps). Yet you end up with a system that puts even bigger clusters of connected systems on the same node? From the pictures it looks like instead of constellations, now huge chunks of regions share the same node. Wouldn't that lead to even more intra-node jumps?
I think that a way more optimal solution would be a kind of checkerboard-style distribution, where systems on one node are geographically close together (to save the poor trio of ratters in Solitude), but not directly connected to other systems on the same node. Several nodes could therefore share the load from people jumping in and out of a big fleet battle, and the majority of jumps would be inter-node jumps.
As others have already said, the new allocation could lead to even higher load being put on the nodes in battles, as it seems now that any sort of reinforcements or auxiliary fights will directly contribute to the load of the fleet fight node itself. And this will also happen with a pre-reinforced node - even if you take the contested system out of the picture, all the surrounding area still shares the same node. Whereas in the old distribution, it is rare to even find a system whose direct neighbors are all on the same node. |
Abdiel Kavash
Paladin Order
Fidelas Constans
2124
|
Posted - 2013.12.03 17:54:00 -
[3] - Quote
Katrina Bekers wrote:Well, for one, Dogma doesn't need to calculate anything about the movement of sentries, and notifications about their movements to any of the clients.
I am not exactly sure why would you say that. Perhaps you think that sentries don't move? They do. |
Abdiel Kavash
Paladin Order
Fidelas Constans
2124
|
Posted - 2013.12.03 18:22:00 -
[4] - Quote
Katrina Bekers wrote:Abdiel Kavash wrote:Katrina Bekers wrote:Well, for one, Dogma doesn't need to calculate anything about the movement of sentries, and notifications about their movements to any of the clients. I am not exactly sure why would you say that. Perhaps you think that sentries don't move? They do. Ok, write me the equation of linear, uniform movement. And tell me about predictability of such movement over time, which is a key part of client-server protocol as of right now. Then the equation of uniformly accelerated motion (aka orbit) -- which can change at owner's whim, anytime. Sure they move. Sure the workload is totally different. QED.
You seem to know quite a lot about the EVE server/client internals. Are you sure you didn't want to post this on your CCP character? |
Abdiel Kavash
Paladin Order
Fidelas Constans
2124
|
Posted - 2013.12.03 18:46:00 -
[5] - Quote
Solstice Project's Alt wrote:Gameplay-wise, it seems that the vast majority of people use their groups of drones as a single unit,
which means that all groups of drones could behave as a single unit,
which also means that the server would only need to do calculations for a single unit.
So, uh, how do you propose shooting and killing drones should work?
Bienator II wrote:i don't know how they reinforce nodes, but they could just take a single system out of the node and put it on a stronger node. They don't have to replace the whole node with all its systems, only pick a single one.
That is exactly what reinforcing a system means. |
Abdiel Kavash
Paladin Order
Fidelas Constans
2124
|
Posted - 2013.12.03 21:30:00 -
[6] - Quote
tiberiusric wrote:Anyway why couldnt you just have a node(s) per region?
1) There are more nodes than regions.
2) Having adjacent systems on the same node is counter-productive (inter-node vs intra-node jumps)
3) Not every region is equally active.
The whole reason behind load balancing is to group systems based on activity: ideally you want to put equal load on every node. What you don't want to happen is one node handling two big fights at once, while another node is "managing" an empty region. It's much better to split the load so that each fight is happening on a separate node. Unfortunately it is currently impossible to move a system from one node to another when a big fight erupts. CCP is trying to map systems to nodes using statistical data so that, on average, the load caused by battles is equally distributed. For specifics read the blog itself. |
Abdiel Kavash
Paladin Order
Fidelas Constans
2126
|
Posted - 2013.12.04 04:20:00 -
[7] - Quote
It is (currently) impossible to move a running system from one node to another without first kicking everyone logged in in that system. But your idea is close to the overall long-term goal. |
Abdiel Kavash
Paladin Order
Fidelas Constans
2135
|
Posted - 2013.12.04 21:47:00 -
[8] - Quote
Andy Koraka wrote:As far as the metagame is concerned, even without a published node map it's going to be exploited. For example in a defensive Sov war, if most of a region is on the same node it's not going to be hard to find a linked system by trial and error and dock/undock repeatedly to cascade the entire node (most of a region in the current scheme) into a sustained 10% tidi to discourage siege fleets from grinding structures.
I wouldn't be too afraid of that. Keep in mind that intentionally putting extra load on the servers is a serious EULA violation. And since CCP are already closely monitoring system load, your docking shenanigans will show up as a big flare. And as soon as some dev looks closer and sees that there is no actual fighting associated with the extra load, you're in trouble.
People have been given warnings and bans in the past for all sorts of exploits trying to force a node to break. |
Abdiel Kavash
Paladin Order
Fidelas Constans
2136
|
Posted - 2013.12.05 04:52:00 -
[9] - Quote
Dersen Lowery wrote:Sentient Blade wrote: The underlying VM has no idea at all it's been moved. And since it's taken a nontrivial amount of time to move relative to the 1HZ physics engine, meaning that the odds are very good that your half a second will cross a tick boundary, that means that every move must be followed by a resync with adjacent systems to get everyone back on the same page, right? If one node is off by a server tick, how do you handle that?
During TiDi different systems are not running in sync either.
(I'm not saying this as a proof that this will be easy, rather as anecdotal evidence for it.) |
|
|
| |
|